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(54) Title: CLINICAL TRIAL DATA MANAGEMENT SYSTEM AND METHOD 
(57) Abstract 

A system and method |Q| 
for managing clinical trial I 
data includes dynamically J 
generating, at a server, 
a data entry form to be 
displayed at a client. 
The data entry form is 
generated dynamically in 
a SGML-derived language. 
Control elements within 
the form comprise images 
which are used to construct 
the control elements 
and larger controls. The 
form is generated from a 
protocol database and a 
context received from the 
client, is populated from 

the data database, and is f f 

published to the client. JOS 107 

Templates based on the 
protocol database comprise 
several frames including 
intermediate frames for 
displaying frame borders 
which are non-horizontal 

and non-vertical. If the trial protocol changes during a trial, the generated form is based on the protocol version active at the time data 
was entered into the form. Inadvertent use of the application is discouraged requiring an authentication procedure and displaying a picture 
of the authenticated user. Furthermore, help is provided by creating a link between the text of each question and information about the 
question. The source of help may be any or all of a protocol document, an investigative brochure, and a study guide. In addition, a user, 
upon logging in, is presented with a dashboard screen which provides information or links to information such as trial-related news, alerts, 
statistical information, progress reports and a list of work to be completed. 
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CLINICAL TRIAL DATA MANAGEMENT SYSTEM AND METHOD 

COPYRIGHT NOTICE 

A portion of the disclosure of this patent document 
contains material which is subject to copyright 
5 protection. The copyright owner has no objection to the 
facsimile reproduction by anyone cf the patent document 
or the patent disclosure, as it appears in the Patent 
and Trademark Office patent file or records, but 
otherwise reserves all copyright rights whatsoever. 

10 BACKGROUND OF THE INVENTION 

Once a pharmaceutical, medical device manufacture 
or bio -technology company has developed a treatment, 
device or drug therapy, approval from a regulatory 
authority, such as the FDA in the US, must be obtained 

15 before it can be made available through prescription. 

The submission to the regulatory authority consists of a 
large volume of information, including clinical 
information which focuses on the safety and efficacy of 
the therapy. Much of that information is collected by 

20 conducting clinical trials. 

A pharmaceutical, medical device manufacture or 
bio -technology company sponsors a series of clinical 
trials. Either an internal clinical group manages these 
trials or they are out-sourced to a clinical research 

25 organization (CRO) . The clinical group or CRO contracts 
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with investigation sites that in turn recruit patients 
for the study and collect the clinical data. 

The clinical trials are performed in a series of 
phases, known as Phase I, Phase II, Phase III, and Phase 
5 IV. Each phase varies in duration, the number of 

patients involved and purpose. Failure at any stage of 
Phases I, II or III of the clinical trial process 
effectively ends the therapy 1 s chances for final 
approval . 

10 Before entering Phase I, the sponsor needs to 

obtain regulatory approval. Phase I trials typically 
last six months and involve tens of volunteer subjects 
usually all of whom are located at a single 
investigative site. Phase I trials test the safety of 

15 the therapy. Once Phase I trials are complete and the 
therapy has been shown to be safe, the sponsor requests 
permission from the regulatory authority to proceed with 
further clinical tests. 

Phase II trials typically last six to twelve 

20 months, involve tens to hundreds of patients and are 
conducted to test the effectiveness of the treatment, 
device or drug. A sponsor may conduct many Phase II 
trials, attempting to find as many uses of the therapy 
as possible. If the therapy appears to be effective, 

25 the sponsor requests permission from the regulatory 
authority to proceed with large scale trials. 

For each likely use of the therapy, the sponsor 
conducts at least two Phase III trials. Phase III 
trials typically last 24 to 36 months and involve 

30 thousands of patients. Phase III trials are blinded 
trials, that is, a portion of the patients receive the 
therapy and the remaining patients receive a placebo or 
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active control, and the identities of patients taking 
the trial therapy are not known to anyone until the 
trial is complete. Phase III trials are conducted to 
test the safety and effectiveness of a therapy in a 
5 large population. The Phase III trial is the first 

opportunity to observe infrequent adverse effects in the 
general population; each and every one is carefully 
recorded. Since the effectiveness of the therapy is 
tested in a blinded environment, the results are not 

10 known until after the study is complete. 

Phase IV trials occur after approval and are 
generally held to obtain approval to change a 
characteristic such as the delivery system, e.g., from 
liquid to tablets, or to change the status, e.g., from a 

15 prescription drug to an over-the-counter drug. Failure 
at any stage of a Phase IV trial effectively ends the 
therapy's chances of obtaining approval for such a 
change . 

Every clinical trial has a protocol which specifies 
20 the exact timing and nature of the measurements and 
interventions to be performed on each patient. The 
protocol's time-line lists a series of events, or 
visits, where the data are collected from the study 
patient. The time-line of a typical study starts with 
25 the screening and enrollment of a patient and typically 
ends with the last patient visit. 

Fig. 1 illustrates the preparation and processing 
of paperwork in a typical clinical trial. There are a 
number of points in the process where the data are 
30 audited and reviewed. A patient 401 visits the 

investigative site 413. For each visit, the protocol 
instructs the investigator to collect certain 
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information 403 about the patient 401. After the 
information 403 is collected, it is recorded on a Case 
Record Form (CRF) 405. Periodically, a Clinical 
Research Associate (CRA) 417 visits the investigative 
5 site 413 and compares the data in the original medical 
record 403 with the information on the CRF 405. This 
process 406 is known as source document validation, or 
SDV. 

Once the CRF has been source document verified, CRF 

10 405 is delivered to the organization 407 running the 

trial (either a CRO or an internal clinical group at the 
sponsor) as indicated by arrow 408. When the CRF 405 
arrives at the sponsor/CRO 407, its data is entered into 
a clinical database 4 09 twice to ensure that no errors 

15 are introduced, as indicated by arrows 410A and 410B. 

A medical monitor 415 and clinical data manager 
(CDM) 419 at the sponsor/CRO 407 examine the CRF 405 to 
look for inconsistencies. If any of the data are 
incomplete or appear incorrect, the CRF is sent back to 

20 the investigative site 413 with a query 411 for 

correction, a process known as cleaning. If someone at 
the investigative site 413 makes a change as a result of 
a query 411, the data is again source document verified 
by the CRA 417, and is sent back to the sponsor/CRO 407 

25 for data entry, as identified by arrow 412. When all of 
the data cleaning is complete, the clinical database 409 
is locked and data analysis begins. 

As can be seen, a large volume of data is collected 
during each clinical trial, and the collection and 

30 management of clinical data is a large problem that 
requires many people performing a number of different 
and unique roles. These roles fall into three groups: 
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the investigative site roles, the clinical data review 
roles, and other central sponsor roles. 

SUMMARY OF THE INVENTION 

Implementing such a system or method on the Web has 
5 the obvious advantage of ease - many people are now 
familiar with Web technology and even those with 
computerphobia are becoming comfortable accessing the 
Web. In addition, because browsers are so inexpensive, 
while the personal computers on which they run can 

10 typically be had for under $1,000, there are no major 
expenses involved for other than the development of the 
clinical trial database. No special software needs to 
be distributed. 

On the other hand, one disadvantage is that access 

15 over the Web can be considerably slower than a direct 
connection to a host server. Another is that certain 
things that can be done easily in a closed environment 
with custom software, such as curved boundaries between 
frames, are not so readily done on the Web. The present 

20 invention is aimed at overcoming these and other 
disadvantages . 

Therefore, a method of implementing a graphical 
user interface (GUI) control element within a client 
browser, comprising creating several bitmaps which can 

25 be constructed to present the GUI control element in a 
variety of different states. A Standard Generalized 
Markup Language (SGML) -derived language such as HTML or 
XML is used to specify placement of the bitmaps within a 
document. Upon receipt of the document, a browser 

30 displays a desired GUI control. 
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Preferably, placement of the bitmaps is specified 
by placing indicators such as URLs corresponding to the 
bit maps in certain locations, preferably table entries, 
within the document, such that the browser will 
5 correctly display the control element. Preferably, 
these bit maps are used by many similar GUI controls. 

Furthermore, a bitmap may be partitioned into 
multiple sections, where each section is associated with 
a different indicator. 

10 In particular, in a preferred embodiment, one type 

of control element is a button control which comprises 
left, right, top and bottom pieces. A label is placed 
between the top and bottom pieces. 

Another type of control element is a file tab, or 

15 tab, control, comprising left, right, top and bottom 
pieces. A label is placed between the top and bottom 
pieces. Multiple tab controls can be grouped together, 
sharing bitmaps which have a left or right overlapping 
piece. Different bitmaps also provide different styles 

20 such as color to portray a selected or non- selected tab. 
Yet another type of control is a linear control 
which comprises button control elements spaced at 
intervals along a line. Each button control element has 
a corresponding bit map or combination of bit maps. A 

25 pointer indicating a current value along the line also 
has an associated bitmap. 

In the preferred embodiment, the server is 
stateless with respect to the GUI controls. That is, 
when a request is received, the server has no knowledge 

30 of the states of the controls other than what is sent in 
the request. 
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The present invention also provides a method of 
entering clinical trial data from a client, where the 
data is maintained on a server. A data entry form to be 
displayed at the client, is generated at the server 
5 dynamically in a SGML-derived language, from a library 
of code fragments. The form is generated according to 
the user, the patient, the protocol version within a 
clinical trial and data previously entered. 

In a preferred embodiment, a protocol, or clinical, 

10 database is created which is specific to an application. 
A data database is created which is specific to a 
subject processed by the application. Then the form is 
generated based on the protocol database, preferably 
based on a clinical protocol, and a context received 

15 from the client. Preferably this is done by generating 
a template based on the protocol database and a context 
received from the client. The form or template is 
populated with application data from the data database, 
and published to the requesting client browser. 

20 Preferably, the template comprises several frames 

including control frames with one or more control 
elements. An intermediate frame presents a visual 
attribute shared by the control frames. The appearance 
of the intermediate frame depends on the visual 

25 appearance of the control frames. 

In addition, in a preferred embodiment, protocols 
can be changed during the trial. The generation of the 
template is then further based on the protocol version 
which was active at time of entering data to be 

30 displayed. Thus the form to be displayed is itself 

based on the protocol version which was active at time 
data was entered. 
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Furthermore, in a preferred embodiment, rules are 
associated with the displayed form, and are based on the 
protocol version which was active at the time of 
entering data to be displayed in the form. 
5 Yet another aspect of a preferred embodiment of the 

present invention is the discouragement of inadvertent 
use of a computer application, by requiring a log-on 
procedure for each user, and displaying a picture of the 
currently logged-on user. 

10 Still another aspect of a preferred embodiment of 

the present invention is the provision of context- 
sensitive help. Preferably, a displayed form has at 
least one question to which a user must respond to 
provide clinical data. Links are created between the 

15 text of each question and detailed information related 
to the question. If the user clicks on text of the 
question, detailed information corresponding to the 
question is retrieved from the server is displayed. 
Preferably, the detailed information is derived 

20 from any or all of three source documents defining the 
clinical trial: a protocol document, an investigative 
brochure, and a study guide. Preferably, the user can 
walk through each of the documents . 

Another aspect of the present invention is the 

25 dashboard screen which provides information regarding 
the trial, customized for the user and presented to the 
user upon logging in to the system. Such information 
preferably includes but is not limited to trial -related 
news, alerts, statistical information, progress reports 

30 and a list of work to be completed 

BRIEF DESCRIPTION OF THE DRAWINGS 



WO 99/63473 



PCT/US99/124G6 



The foregoing and other objects, features and 
advantages of the invention will be apparent from the 
following more particular description of preferred 
embodiments of the invention, as illustrated in the 
5 accompanying drawings in which like reference characters 
refer to the same parts throughout the different views. 
The drawings are not necessarily to scale, emphasis 
instead being placed upon illustrating the principles of 
the invention. 
10 Fig. 1 is a block diagram illustrating current 

trial data collection practice. 

Fig. 2 is a block diagram illustrating the present 
invention's implementation of a clinical trial data 
management system operating over the Internet and the 
15 World Wide Web. 

Fig. 3 is a block diagram illustrating the general 
flow of operation and data in the present invention. 

Fig. 4A is a diagram illustrating a Web page 
comprising a typical clinical form created by the 
20 present invention. 

Figs. 4B and 4C are illustrations depicting the 
hierarchical structure of a form such as that of Fig. 4A 
within the present invention. 

Fig. 4D is a schematic diagram illustrating the 
25 dynamic construction of a form template and the 
resulting document within the present invention. 

Fig. 5 is a diagram illustrating how the form of 
Fig. 4A might appear for a different user. 

Fig. 6 is a diagram of a login screen. 
30 Fig. 7 is a diagram illustrating the dashboard 

screen of the present invention. 
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Fig. 8 is a diagram illustrating intermediate 
frames as used by the present invention. 

Fig. 9 is a diagram illustrating how a button 
control of the present invention comprises bit maps laid 
5 out in a table. 

Fig. 1 OA- 10C are diagrams illustrating how the tab 
control of the present invention comprises bit maps laid 
out in a table. 

Fig. 11A-11D are diagrams illustrating a linear 
10 control of the present invention. 

Fig. 12A is a flowchart illustrating the present 
invention's use of study protocol version control. 

Figs. 12B and 12C are illustrations showing the 
same form under two different protocol versions. 
15 Figs. 13A-13F are diagrams illustrating the use of 

context sensitive help as employed by the present 
invention. 

DETAILED DESCRIPTION OF THE INVENTION 

The present invention provides a means of 

20 expediting the process by collecting and managing trial 
data including communications between sites over the 
Internet, using a World Wide Web (Web) server in 
combination with Web browsers which run on most personal 
computers. Such a system requires little to no 

25 investment. Communication between parties is near- 
instantaneous, and can be saved as part of the record. 
Checks can be performed automatically and 
instantaneously. This allows faster processing of the 
data, and faster availability of the data. A 

30 significant amount of time is cut out the trial time, 
allowing the sponsor to get its product to market 
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sooner, saving millions of dollars, and potentially 
aiding thousands or millions of potential recipients of 
the treatment much sooner than the treatment might 
otherwise be available. 
5 The Internet is a world-wide computer network which 

actually comprises thousands of smaller networks 
connected to the Internet backbone, thus linking 
millions of computer users around the world. The Web is 
a technology which allows a user to format a document 

10 according to some standard. The document is made 

accessible to a Web server which transmits the document 
to another user upon request . When the document is 
received by the requestor running a Web browser, the 
browser knows how to construct and display, or render, 

15 the document. 

Requests are made to a Web server using a Uniform 
Resource Locator (URL) which identifies the Web server 
and the specific document. These documents are often 
called Web "pages" . 

20 One common format for transmitting these documents 

is known as Hypertext Markup Language (HTML) . HTML 
allows the creator of a document to specify the 
appearance and placement of a variety of things such as 
font size, style, headers and so, including placement of 

25 data or pictures within tables. 

If a Web page is to contain pictures, these 
pictures or images are often specified within the 
document by their respective source locations, where 
they are stored as image files using formats such as 

30 "gif" or "jpeg", for example. These image files can be 
quite large and can consume an annoyingly large amount 
of time as a requesting party waits for the image files 
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to download. Of course, this is compounded when there 
are several image files to be downloaded. 

One feature of most Web browsers is the ability to 
cache information locally. Thus image files can be 
5 stored in the browser's cache, so that if the user 

requests the same page at a later time, the browser uses 
the locally cached image files rather than downloading 
the files again. While this saves much of the time that 
would otherwise be wasted re -downloading the images, it 

10 does come with a cost: image files can be large and 
caching many of them for hundreds or thousands of Web 
pages can consume a significant portion of local memory 
or disk space. 

Fig. 2 illustrates the present invention operating 

15 over the Internet. The Clinical Research Organization 
(CRO) or the sponsor's own internal clinical group 
responsible for maintaining trial data maintains an 
application server 103 which stores data about the 
protocol, the forms to be used, the roles of various 

20 individuals involved, etc., in a meta database 105. 
Actual clinical data collected during a trial is 
maintained in a trial database 107. Of course, while 
there are logically two databases, the actual data can 
be maintained in just one or many databases. 

25 The application server 103 receives requests via a 

network 109, such as the Internet, from users 111 at the 
investigative sites 112, sponsor sites 113, and CRO 
sites 114, and responds to the requests, presenting a 
consistent and secure interface through a Web server 

30 101. The Web server 101 transmits information to the 
requesting site as a document formatted according to an 
SGML -derived language, such as XML, or preferably, 



WO 99/63473 



-13- 



PCT/US99/12406 



hypertext markup language (HTML) document. The document 
can also include small scripts in a language such as 
Javascript for implementing certain rules at the user's 
site. Investigative sites 112 include, but are not 
5 limited to, hospitals, clinics and independent doctors' 
offices . 

During a clinical trial, various individuals have 
certain responsibilities which are accompanied by 
privileged access to certain documents. In the present 

10 invention, these privileges are rigidly defined. Roles 
are defined as a collection of privileges such that 
assigning a particular individual to a defined role 
bestows upon that individual the collection of 
corresponding privileges. 

15 For example, in the present invention, there are 

two primary roles at the investigator site. The 
Clinical Investigator and the Clinical Research 
Coordinator (CRC) gather the data for the trial 
according the protocol, and record the data on CRFs 

20 which are sent to the sponsor for review and acceptance. 

The Clinical Investigator (CI) is responsible for 
treating his patients and executing the study protocol. 
He has the ultimate responsibility for all activities at 
his site. 

25 The CRC is responsible for collecting all of the 

information about the patients in the study who are 
being treated at the CRC's site, and for returning the 
information to the clinical group. In the US this 
individual is typically a nurse, while in Europe the 

30 role of the CRC is typically performed directly by the 
Clinical Investigator . 
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The people fulfilling these roles at the 
investigation site must be able to see information about 
all of their patients who have been screened or accepted 
into the study. This information includes a patient's 
5 visit history, the contents of the CRF associated with 
the patient, and the patient's lab results to name a 
few. 

As clinical reviewers at the CRO or sponsor examine 
the answers to the CRF questions, they may have 

10 questions or comments which require responses from the 
investigation site. These questions and comments are 
referred to as queries. The CI or CRC must be able to 
respond to a query, usually by attaching a comment to a 
question or CRF, by adding new or additional information 

15 to a CRF, or by changing information previously entered 
on the CRF. This is a key component of data cleaning. 
Once the query is resolved, the response is returned to 
the individual reviewer who issued the query. 

During the course of a trial, some patients may 

20 experience adverse events. These events are noted by 
recording a text description of the event, as well as a 
medical code for that event . These codes are found in a 
number of coding dictionaries such as COSTART. If the 
adverse event is serious, the sponsor is notified 

25 immediately. 

Some patients in the trials may take other 
medications during the trial. These medications, 
whether taken regularly as for allergy medication, or 
occasionally such as aspirin for a headache, are 'coded 1 

30 and stored in the patient's record. 

From time to time, the CI or CRC at the 
investigation site must review some of the information 



WO 99/63473 



-15- 



PCT/US99/12406 



about the study such as the study protocol, the study 
reference manual, a study newsletter, and a list of 
frequently asked questions. In addition, they must 
review information about individual questions on the CRF 
5 such as getting a list of all previous responses to a 
question and viewing the discrepancy criteria for a 
question. 

During a trial, a CI or CRC may need to communicate 
with a representative of the sponsor. For example, 

10 initially the CI/CRC needs to provide information about 
the site to the sponsor (Form 1571, lab normals, CVs of 
the investigator) . As the study progresses, the CRC may 
have a question or may notice something that would 
interest the sponsor. Much of this communication is 

15 included in the study files. 

In addition to communication with the sponsor, the 
investigation site may want to communicate with another 
site. Perhaps an investigation site wants to ask 
someone at another site a question. These 

20 communications are not part of the study data. 

In addition to written communication with the 
sponsor, frequently the site will call someone at the 
sponsor. The content of many of these conversions may 
need to be noted in the study data. 

25 The study protocol may require a CI /CRC to sign 

the CRF pages either before the CRA performs the source 
document verification, when the patient book is complete 
or both. The signature task can be made easier for the 
investigator site by telling them which CRFs are 

30 complete and need a signature, and when data on a signed 
CRF has changed and needs another signature. 
Additionally, the investigator sites need to know which 
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CRFs they have examined and which ones they have not 
examined . 

The management of drug inventory during a study is 
critical. A complete accounting of all study medication 
5 is required by the regulatory agencies. The 

investigator site needs to dispense study medication to 
their patients in the study and record this transaction. 
Additionally, when the sponsor issues study medication 
to the investigator site, this transaction and the 

10 receipt of the study medication by the investigation 
site must also be recorded. 

Occasionally, the investigator site will need to 
break the study blind for a particular patient (for 
example, when a study patient becomes pregnant.) This 

15 is an important transaction and it must be noted in the 
study data. 

There are four clinical review roles to be 
performed at the Clinical Research Organization (CRO) 
and/or sponsor. The Clinical Research Associate (CRA) , 

20 Clinical Data Manager, Medical Monitor, and Clinical 

Project Manager review the data that is generated by the 
investigator sites for completeness and consistency. 

The Clinical Research Associate reviews all of the 
data provided by the investigator sites, ensures that 

25 the sites are following the protocol and that all of the 
information in the medical record is completely and 
accurately represented in the study data. Typically, a 
CRA is responsible for monitoring a number of sites, and 
their audit role requires them to visit their sites. 

30 The CRA needs to know exactly what is happening at all 
of their sites so that they can effectively monitor the 
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site's activities. The CRA sends summary reports to the 
project manager and others at the sponsor. 

The Clinical Data Manager (CDM) prepares and 
maintains the clinical study database. The CDM is 
5 involved in the design of the study database, validation 
checks, and the design of the CRFs. The CDM also 
reviews the data in the database ensuring that the data 
is complete and consistent. 

The Medical Monitor is often the designer of the 

10 study protocol and may be responsible for making any of 
the necessary changes to or deviations from the protocol 
once that study has begun. The Medical Monitor also 
reviews the study data looking for data anomalies and 
irregularities with respect to patient safety. Like the 

15 CRA, the Medical Monitor reviews the data in the CRFs 
and the communications with the sites. The Medical 
Monitor may respond to a query from a CRA. Finally, the 
Medical Monitor is immediately notified whenever a 
serious adverse event is recorded. 

20 The Clinical Project Manager oversees the entire 

data collection process. They directly manage the 
activities of the CRAs and CDMs and at times they will 
examine the study data in detail . Together with the 
Medical Monitor, the Clinical Project Manager reviews 

25 the progress of the study and reports status to the 
senior management at the sponsor. 

To monitor a site effectively, a data reviewer 
periodically reviews the data in the CRFs. If a value 
is missing, the validity of a value is questionable, or 

30 there is some other cause for concern, the data reviewer 
issues a query by attaching a question or comment to a 
question on the CRF. 
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Before a clinical database can be locked, members 
of the review team may be required to sign the patient 
CRF books. The signature task is simplified by 
indicating which CRFs are complete and need a signature, 
5 and which data on a signed CRF has changed and requires 
another signature. In addition, the data reviewer needs 
to know which CRFs have already been examined and which 
have not been examined. 

Just as the site must on occasion communicate with 

10 the sponsor, the data reviewer must communicate with a 
site. These communications may or may not be included 
in the study data. In addition, some messages are 
critical and investigator site personnel must see these 
messages before continuing. 

15 Data reviewers need to communicate with each other. 

A CRA may have a question for the medical monitor, or 
the medical monitor may notice something that they would 
like the CRA to investigate. Unlike queries, these 
communications are not part of the study database. 

20 Occasionally, one or more of the data reviewers 

will want to lock some or all of the patient 1 s records 
so that interim statistical analysis can be performed. 
A preferred embodiment of the present invention provides 
a mechanism for locking the data at a patient level. 

25 The Clinical Research Associate (CRA) , has specific 

additional functions, as well. The CRA can view an 
investigator site's data and issue queries to the sites. 

Periodically, the CRA visits a site, reviews all of 
the data in the original medical records (the source 

30 documents) and compares this with the information in the 
CRFs. This is known as source document verification. 
The CRA monitors a CRF at the question level, meaning 
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that part of a CRF could be considered reviewed, but the 
rest will still need monitoring at a later time. In a 
preferred embodiment of the present invention, the CRA 
is automatically notified when any CRF is ready for 
5 review. 

The CRA often does not have access to the primary 
study database and must work off-line. Therefore, during 
verification the site cannot change the data being 
reviewed until after the review is complete. 

10 The CRA must manage the documents that are provided 

by the site. These include any regulatory documents and 
any additional documents that are generated by the site 
that must be included with the study data. The CRA must 
notify the site when one of these documents is about to 

15 expire. 

From time to time, the CRA issues a report about a 
site. For example, these reports are issued when a site 
has been qualified for the study, when a site initiates 
a trial, after the CRA has monitored some of the data at 

20 a site, and when a site finishes its last study patient. 

The Clinical Data Manager (CDM) also has specific 
additional functions. During the course of a trial, the 
CDM may need to change one or more of the discrepancy 
checks in the system. 

25 Typically, codes are entered not by the study 

coordinator (CRC) but rather by the CDM. If a CRC 
enters an adverse event or concomitant medication 
without coding the data, the CDM supplies the 
appropriate code in the database. In addition, the CDM 

30 carefully reviews all coding of adverse events and 
concomitant medications, making any changes that are 
necessary for consistency. 
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The Medical Monitor is notified whenever a serious 
adverse event is recorded. This notification occurs as 
quickly as possible to ensure the safety of the affected 
patient and all other patients in the study. 
5 The sponsor will occasionally send information to 

all members of the study team and/or to all of the 
sites . 

In addition, it is occasionally necessary for the 
Medical Monitor to change some part of the study 

10 protocol or CRFs. If the change affects patient safety, 
the protocol change must be reviewed by an Institutional 
Review Board at each site before it can be implemented. 
This leads to the possibility that two or more versions 
of the protocol could be active at different sites 

15 simultaneously. 

On rare occasions the Medical Monitor allows a site 
to violate the study protocol. When this occurs, there 
must be a documented record of the deviation with the 
Medical Monitor's approval. Additionally, the Medical 

20 Monitor must note the justification for the deviation in 
the study data. 

Occasionally, the Medical Monitor will need to 
break the study blind for a particular patient (for 
example, when a study patient becomes pregnant) . This 

25 is an important transaction and it must be recorded in 
the study data. 

The Clinical Project Manager will sometimes act as 
an individual contributor CRA or CDM. 

There are two other roles in the system which do 

30 not fit into any of the other categories. They are the 
Pharmacist and the Database Manager. Many investigator 
sites will have their own pharmacy on site, or they will 
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work with a local pharmacy. In either case, the 
Pharmacist must have access to the clinical trial data 
application. 

The Database Manager is responsible for the 
5 security and reliability of the clinical study database. 
During the design of the trial, the Database Manager 
works with the CDM designing the implementation of the 
data model for the trial. At the end of the trial, the 
Database Manager is responsible for moving the data out 
10 of the study database and into a statistical analysis 
database. 

From time to time, a pharmacist must review 
information about the study such as the study protocol, 
the study reference manual, a study newsletter, and a 

15 list of frequently asked questions. During the study, 
the pharmacist may need to communicate with the sponsor 
personnel. As the study progresses, the pharmacist may 
have a question or may notice something that would be of 
interest to the sponsor. Some of these communications 

20 must be included in the study data. 

The management of drug inventory during a study is 
critical. A complete accounting of all study medication 
is required by the regulatory agencies. The site needs 
to dispense study medication to their patients in the 

25 study and record this transaction. In addition, when 
the sponsor issues study medication to the site, this 
transaction must also be recorded. 

When the study is complete and the database is 
locked, the Database Manager must move the study data 

30 into a statistical database. The database structures of 
the clinical database must support this conversion. 
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Fig. 3 illustrates the general flow of operation 
and data in the present invention. While any Standard 
Generalized Markup Language (SGML) -derived language such 
as XML can be used, the preferred embodiment of the 
5 present invention utilizes Hypertext Markup Language 

(HTML) . Rectangular boxes and solid bold lines indicate 
process flow, while dotted lines indicate data flow. 

First, at 201, a request is received from a user, 
i.e., an investigative site, a sponsor site, a CRO site 
10 or a pharmacist. The request 213 is saved for later 
processing by any or all of the authentication process 
203, the application layout process 205, or the form 
creation process 207. 

Upon receipt of a request from a client, the 
15 authentication process 203 is invoked. A user database 
215 is maintained, and the authentication process 203 
checks user information contained in the request 213 
against the user database 215. Such information may 
contain user identification, password, session 
20 information, valid time frame, etc., or other equivalent 
authentication means. 

In addition to authenticating the user, the 
authentication process 203 examines the user request 213 
and checks with the user database 215 that the user is 
25 authorized to make such a request. The authentication 
process 203 can then establish which user rights 217 the 
user is to be given regarding the response to the 
particular request. 

Once the requesting user has been authenticated, an 
30 application layout process 205 begins to construct the 
layout of the HTML response 221 to the client. This is 
a top layer describing what pieces are to be positioned 
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within the HTML document and where. For example, this 
layer determines what the various frames should look 
like and what controls should appear therein. To make 
these decisions, the application layout process 205 
5 relies on the original user request 213, the user rights 
217 as determined previously by the authentication 
process 203, and descriptors maintained in a descriptor 
database 219. 

Once the layout has been generated, the form 

10 creation process 2 07 uses the user request 213 and 
descriptor database 219 to determine what questions, 
controls and other information should go into the form 
in the HTML document 221 previously laid out by the 
application layout process 205. 

15 Next, the HTML document 221 is populated with 

clinical data by a data population routine, which 
retrieves the data from a trial database 223. The 
document 221 is now complete and ready for transmission 
back to the client (block 211) . 

20 Fig. 4A illustrates a typical Web page 250 created 

by the present invention, as constructed from the HTML 
document 221 (from Fig. 3) when received and displayed 
by a client browser. Panels 251A-251C derive from the 
part of the HTML document 221 constructed by the 

25 application layout process 205 (Fig. 3), and contain 
various controls and other general information. 

For example, panel 251A contains a photograph 257 
of the person whose user identifier and password were 
used to first gain access to the system, or login. As 

30 discussed below, a preferred embodiment of the present 
invention displays this photograph 257 for the purpose 
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of discouraging inadvertent use of the system by another 
person. 

Other controls 261 are also provided in this panel 
251A which permit the user to navigate to and examine 
5 various related documents and other information pages. 
Links 269 to recently accessed documents or data are 
also provided. 

Panel 251B holds two additional controls: a time 
line control 263, and a file tab control 265. These are 

10 special types of controls which were necessitated by the 
present invention, yet are not easily implemented in a 
Web application. They are discussed below. Note 
however, that the time line control 263 is used to 
select a specific week (or some other unit of time) 

15 within the study, and that the file tab control 265 is 
used to select a particular form. Appearance of the 
form, of course, is dependent on the user's role, the 
protocol version and the week selected, as well as the 
actual form selected. 

20 Finally, panel 251C holds controls 267 related to 

the form, here a Submit button and a Cancel button. 

Once the panels 251A-251C are laid out by the 
application layout process 205, the selected form layout 
253 is specified by the form creation process 207 (Fig. 

25 3) . In Fig. 4A, the "Demographics" form is displayed. 

Figs. 4B and 4C depict the hierarchical structure 
of an electronic CRF 253, also referred to simply as a 
form, of the present invention. The form 253 comprises 
one or more sections 551. Two sections 551 of the 

30 Demographics form 253 are visible: a Demographics 

section and a Smoking History section The remainder of 
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the form can be brought into view by scrolling the 
scroll bar 553 . 

Each section comprises one or more items in which 
the user is typically asked to provide information about 
5 a patient, or if the information has already been 
provided, the information is displayed. For example, 
the Demographics section 551 has six items 554 numbered 
from 1 to 6, as well as a seventh item 555 in which a 
calculation is automatically performed by the system. 

10 Each item 554 in turn may comprise one or more 

control groups 556. For example, item 2 ("Date of 
Birth") comprises control group 556, which in turn 
comprises three controls 557A-557C (generally 557 in 
Fig. 4C) . Note that a control group may itself comprise 

15 control groups. 

Each control may have one or more elements. For 
example, control 557A allows a user to select the 
patient's date of birth month. The twelve months are 
available in a list which is made visible by clicking on 

20 the arrow. Each month is an element 558 of the control 
557A. 

The significance of this hierarchy is that each of 
these hierarchical levels is treated as an object, with 
its own HTML fragments. As illustrated in Fig. 4C, when 

25 a user sends a request 201 for a specific form, the 

associated form object 253 is called up and passed user 
559 and form 560 information. Form construction is 
begun by selecting certain HTML fragments. The form 
object 253 then determines from the trial database 

30 including information about the protocol version, and 
from user privileges and patient information, which 
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sections are to be included, and those section objects 
are then called by the form object to render themselves. 

As with the form object, each section object has 
its own HTML fragments, some of which are selected. 
5 This process continues, each object in the hierarchy 
selecting HTML fragments according to the user 
privileges, and calling its embedded objects. 

Fig. 4D further illustrates how the HTML document 
211 is constructed dynamically from fragment templates 

10 and from data. A trial database 220 stores structural 
information of the form object hierarchies as previously 
discussed. A descriptor database 219 is essentially a 
library of HTML code fragments. These two databases 
together make up the meta database 105. A clinical 

15 database 223 stores data collected during the trial. 

For example, the Demographics Form is described as 
having two sections, Section 1 and Section 2. In the 
preferred embodiment, pointers are used, such as the 
pointer 230 to Section 1. Each section in turn has 

20 pointers to its items, and so on. 

Each part of the hierarchy also points to 
corresponding code fragments in the descriptor database 
219. For example, the high level Demographics form 
object comprises a pointer or identifier 231 which 

25 points to various code fragments 234. The object 
decides which fragments to use and which to reject, 
depending on user rights. The selected template 
fragment is copied (indicated by 238) into the document 
211. 

30 Each object in the hierarchy behaves similarly. 

Section 1 object data in the trial database 22 0 has a 
pointer 232 to its own corresponding code fragments in 
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the descriptor database 219. Again, those code 
fragments or templates selected, such as code fragment 
235, are copied into the document 211, as indicated by 
arrow 23 9. 

5 In addition, the object for Section 1 also has a 

pointer to data 236 stored in the clinical database 223 
which is combined, in the output document 211, as 
indicated by arrow 24 0, with the fragment template 235. 
The data 236 is copied, as indicated by arrow 241, into 

10 the document 211, and replaces some placeholder from the 
original fragment. The copied data is indicated by 
reference 242 . 

Finally, the output document 211 is sent, or 
published, to the requestor, whose browser renders the 

15 form. Arrow 243 demonstrates how one of the section 

fragments with trial data is rendered into a section 204 
of the form. 

Of course, the clinical data is initially entered 
by the CI/CRC and stored in the trial database when 

20 submitted. Upon later retrieval for review or editing 
(assuming proper user rights) , the stored data is filled 
in under the data population process 209 (Fig. 3) , 
wherein individual control or element objects retrieve 
and display actual clinical data from the clinical 

25 database 223. 

Note that while code fragments are generally in the 
form of HTML statements, they can also contain small 
scripted statements written in a language such as 
Javascript, which might be used to implement certain 

30 rules. For example, a rule might allow patient 

temperatures only within a certain range, to protect 
against the entering of Celsius temperatures instead of 
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Fahrenheit. Checking with rules at the browser using a 
language such as Javascript obviates the extra 
transmissions back and forth that would be required if 
all checks were to be done at the server. Such rules 
5 may be based on the protocol which was active at the 
time certain data was entered. 

In Fig. 4B, an inconsistency in the data has been 
found. The user has indicated in Question 7 that the 
patient has never smoked, yet in Question 9 has 
10 indicated that the patient smokes cigarettes. Thus a 
query 271 has been entered by a CRA asking for further 
verification and appears on the form for the user to 
respond to. 

Finally, note that the text of each question is a 

15 link to additional information. For example, the text 
271 of Question 5, "Weight" is a link to one of several 
documents explaining weight in the context of the 
protocol. This is discussed further below. 

Fig. 5 illustrates how, in the preferred 

20 embodiment, the same form can differ for a different 
user with a different role and therefore different 
access rights. Here, User2 is a Clinical Research 
Associate (CRA) with the Sponsor. The Sponsor is not 
allowed to enter or alter data. Thus patient data at 

25 275 is simply displayed as text and is not editable. No 
controls are available. 

Note also that for User2, different controls 277 
are provided in the application layout panel 251A. 
Here, there are two additional controls: Signatures and 

30 Monitor, because these are CRA functions. Note also 
that because the form does not allow data entry, the 
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controls in pane 251C are also different from those of 
Figs. 4A and 4B. 

Preventing inadvertent use 

Fig. 6 illustrates a typical login screen of the 
5 present invention as displayed on a client browser. A 
user is asked to provide an account name 2 93 and a 
password 295. Upon clicking on the Log In button 297, 
the account name and password are transmitted over the 
Internet to the Web Server 101 (Fig. 2) where they are 

10 then submitted to the Application Server 103 for 

authentication. Alternatively, authentication could be 
performed using alternative methods such as a secure 
identification card, digital certificates or biometric 
characteristics . 

15 A preferred embodiment of the present invention 

displays a photograph 257 (Fig. 4A) for the purpose of 
discouraging inadvertent use of the system by another 
person. For instance, if the person logged in happens to 
walk away for a break, take a telephone call, etc. and 

20 another user comes along and logs in using his own 
login, and this second user takes a break, while the 
first user returns, the first user will see instantly 
that she is no longer logged in. A photograph catches 
the attention of the user much more readily than would a 

25 text -only name. 

In the preferred embodiment, the name and role 259 
of the logged- in user are provided under the photograph 
257. Thus, if the first user forgot to log out, a 
second user coming upon the system, and unfamiliar with 

30 the first user, could visually identify the first user, 
or, if unable to find the first user, because the name 
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is provided, could look the first user up in a directory 
if it were necessary to contact the first user. 

Inte grated Dashboard 

In a preferred embodiment, when the user has been 
5 authenticated, a "dashboard" 301 customized to the user 
is returned to the client browser and displayed. 

Fig. 7 is a diagram illustrating the dashboard 
screen of the present invention. The dashboard 3 01 
contains various information and links regarding the 
10 study. For example, it contains study news 3 03 which 
the user should read and alerts 3 05 which may be 
critical. It also contains study progress graphs 307, a 
list of work to be completed 3 09 with navigational 
links, and additional information. It serves as a home 
15 base for the user. 

Intermediate Frames 

While frames with curved corners can be 
aesthetically pleasing, HTML frames do not provide such 
curved borders. Thus one aspect of the present 
20 invention is the use of intermediate frames to provide 
the curves . 

Fig. 8 is a diagram illustrating the use of an 
intermediate frame by the present invention. Normally, 
a Web display may be broken down into several 
25 independent frames. Here, Web page 400 is divided 

functionally into three independent frames: a control 
panel frame 403, a content action panel frame 405 and a 
content panel frame 407. 

The developer of the Web site wishes to use a 
30 curved line 401 to visually differentiate the panels 
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from each other. However, in HTML, frame borders are 
limited to horizontal and vertical lines. 

A preferred embodiment of the present invention 
simulates curved or irregular shapes between frames by 
5 using an intermediate frame 409 between frames 403, 405 
and 4 07 in which the curves and other frame borders are 
drawn. Thus, it appears to the user that the various 
panels actually have curved borders. 

Bit Mapped Controls 

10 As discussed earlier, in a preferred embodiment of 

the present invention, typical GUI controls which are 
normally executed in a stateful machine are implemented 
in a client browser. This is done in the preferred 
embodiment of the present invention by creating several 

15 bitmapped images which can be selectively placed such 
that the browser properly constructs the desired 
control. Bitmapped images may be formatted as gif, jpeg 
or other formats. Because browsers cache images 
locally, reuse of most of the bitmaps in multiple 

20 control elements results in rapid construction of the 
control element and thus the Web page. 

One advantage of this approach is that because many 
of the images are reused, only one copy of each needs to 
be downloaded from the server. Second, labels are 

25 simple text and do not have associated images to be 
downloaded. The text is small and thus takes only a 
short time to transfer. Finally, because the image 
files corresponding to the bitmaps are locally cached by 
a browser, and because the image files are small, they 

30 consume only a small portion of memory. 
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Fig. 9 illustrates this concept with a button 
control 501 containing the text label "ABC" 503. 
Ordinarily this entire button 501 is a single image. If 
many buttons are used, say having labels "DEF" , U GHI" 
5 and so on, each must have a completely different image, 
each requiring its own initial transfer time and its own 
cache storage. 

Instead, the present invention breaks the button 
image into several images 505A-505D. References or 

10 indications such as URLs to these images (which, in the 
preferred embodiment are generally "gif" files) are 
placed into a TABLE structure in an HTML document. Such 
a table 506 has five data entries, labeled 506A-506E. 
References to images 505A-505D are placed in four of the 

15 table entries 506A-506D, resulting in the placement by a 
browser, of the images in the table 506, as indicated by 
arrows 509A-509D respectively. The label text "ABC" is 
placed, with a background color matching the images 
505A-505D, into the remaining table entry 506E. 

20 Thus, while the application may use many different 

buttons, only the labels are different - the same images 
are reused by all of the buttons. No additional image 
files need to be transferred over the Internet. Only 
the text needs to be transferred and text takes but a 

25 fraction of the time an image takes to transfer. Since 
the images are reused, storage in the cache is much 
smaller as well. 

Note also that an HTML-compatible browser 
automatically extends bitmapped images to fit a required 

30 space. Since a table adjusts itself to contain its data 
entries, a button 501A having a long label 503A (say the 
entire alphabet) would be drawn having a label space 
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506E long enough to contain the entire label. Table 
entries 506B and 506C would be lengthened accordingly, 
and therefore bitmapped images 505B and 505C would be 
extended to fill these lengthened entries, even though 
5 only minimal descriptions of the bitmaps is provided. 

Below is sample HTML code to produce a button from 
several gif files. Bitmap images 505A-505D (Fig. 9) 
correspond to files named respectively 
"but_bot_lef t . gif" , "but _bot_top . gif" , 

10 "but_bot_right.gif", and "but_bot_bot .gif " . The label 
of this particular button is "Go" . Note also that each 
of the table entries has the text: HREF= "tabs . htm" . 
Thus clicking anywhere on the button will cause the 
browser to request a Web page identified as "tabs. htm". 

15 <HTML> 

<i "////////////////////////////////////////////////// 

- - > 

<!--// Copyright (c) 1997-1998 Phase Forward Inc. 

- - > 

20 <!--// 51 Winchester Street, Newton MA 02161 

- - > 

<!--// All Rights Reserved 

<i "////////////////////////////////////////////////// 

25 

<HEAD> 
< STYLE > 
TD 

{ 

30 font -size: 8pt; 

font-family: Arial,"Sans Serif"; 

text - al ign : center ; 

vertical -align: middle; 

font -weight : bold ; 
35 color :#CCCCCC; 

} 

TD . menu 

{ 

line-height : lOpx; 
40 height: 8px; 



WO 99/63473 



-34- 



PCT/US99/12406 



} 

TD.TDLeft 
{ 

text-align: left; 
5 vertical -align: middle; 

} 

TD . TDRight 

{ 

text - al ign : right ; 
10 vertical-align: middle; 

} 

A: link 
{ 

color: #CCCCCC; 
15 font-size: 8pt; 

font -family: Arial,"Sans Serif"; 
font -weight : bold; 
text-align: center; 
text -decoration : none ; 

20 } 

</ STYLE > 

</HEAD> 

<BODY> 

<TD NOWRAP TITLE= "Click here to go to the patient 
25 visit"> 

< TABLE BORDER= " 0 " CELLS PACING= 11 0 " CELLPADDING= " 0 " 
VALIGN= "middle" ALIGN= " lef t " > 
<TR> 

<TD ROWSPAN="3" NOWRAPxA HREF= » tabs . htm" >< IMG 
30 SRC=" ./images /but_bot_l eft. gif " 

BORDER= » 0 » ></A> < /TD> 
<TD NOWRAPxA HREF= » tabs . htm" >< IMG 

SRC=" ./images/but jDot_top.gif " WIDTH="34" 
HEIGHT= "4 » BORDER= » 0 " ></Ax/TD> 
35 <TD ROWSPAN="3" NOWRAPxA HREF= " tabs . htm" x IMG 

SRC= " . /images/but_bot_right . gif " 
BORDER^ " 0 " ></Ax/TD> 

</TR> 
<TR> 

40 <TD CLASS="menu" BGCOLOR=" #336699" NOWRAPxA 

HREF=" tabs, htm" >Go</Ax/TD> 

</TR> 
<TR> 

<TD NOWRAPxA HREF=" tabs . htm" x IMG 
45 SRC=" . / images /but_bot_bot .gif " WIDTH="34" 

HEIGHT = » 5 » BORDER= " 0 " x/Ax/TD> 

</TR> 
</TABLE> 
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</TD> 
</BODY> 

Note that in HTML, a table structure is delimited 
by the < TABLE > and </TABLE> tags. Each row begins with 
5 the tag <TR> and optionally ends with </TR>. Within 
each row, each column, or table data, begins with <TD> 
and optionally ends with </TD>. A COLSPAM=X or 
ROWSPAN=Y specification within a <TD> tag indicates that 
the corresponding entry is to span X columns or Y rows 

10 respectively. 

Figs. 10A, 10B and 10C illustrate a file tab, or 
tab, control used by the present invention. Fig. 10A 
shows a tab control 421 having three tabs, although a 
tab control with any number of tabs can be implemented 

15 with this technique. As shown, the first tab element, 
labeled "ABC" is selected. 

The tab control 421 is subdivided into many small 
sections, shown individually in Fig. IOC, each of which, 
except for label sections, has a corresponding image. 

20 As with the button control, many of the images are 

reused. Each image has a shaded version and an unshaded 
version. A tab is shaded if it has been selected. For 
example, a right piece bitmap 437 , a top piece bitmap 
425, and a bottom piece bitmap 429 define most of the 

25 third "GHI" tab. The label 435 is not a bitmap but 

rather, as with button labels described above, is simply 
text with a background color to match the surrounding 
bitmaps. Bitmap 431 is shared by the "GHIC" tab and the 
adjacent "DEF" tab. 

30 The "DEF" tab uses the same top and bottom piece 

bitmaps 425, 429. Therefore, these bitmaps will not 
have to be transferred again since they were just 
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transferred in order to draw them into the "GHI" tab. 
Of course, the "DEF" tab here uses a unique label 
("DEF"), but since that is simple text, it is placed 
directly in the table structure and as a result there is 
5 no significant overhead in its transmittal. Another 
overlapping piece bitmap 43 1A is shared between the 
"DEF" tab and the selected "ABC" tab. 

The "ABC" tab uses shaded left, top and bottom 
piece bitmaps 423A, 425A, 429A respectively, to show 

10 that the "ABC" tab is selected. The label "ABC" 427 is 
data embedded directly in the table data definition. 

Each of these small bitmap images has a HREF 
element assigned to it, i.e. a reference to send to the 
server if the user clicks the mouse button on the 

15 bitmap. Although the same top bitmap 425 is used for 
multiple tabs, each realization of the bitmap may have a 
different HREF assignment. Thus, for example, when the 
user clicks anywhere within any of the top 425 or bottom 
429 bitmaps or the label 427 associated with the "DEF" 

20 tab, information regarding "DEF" may be retrieved from 
the server and displayed on the browser. In addition, 
the tab control appearance must change to indicate that 
"DEF" has been selected. 

Thus, the tab control now appears as shown in Fig. 

25 10B. Only two new images are required: the shared 

bitmap 43 1A between the "ABC" and "DEF" tabs has been 
replaced by a bitmap 43 9A with a different overlapping 
appearance, and the leftmost piece 423A is no longer 
shaded and must be replaced with piece 423 . These are 

30 the only piece of the tab control that need to be 
provided by the server. 
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As with the button discussed above, without this 
technique, it is necessary to download and cache the 
entire tab control in each of its three possible states, 
i.e. three bitmap of the entire tab control, each with a 
5 different tab selected. This requires much more cache 
memory than the present invention, as well as much more 
transmission time when the maps have not been cached 
(and each transmission is a transmission of the entire 
tab control bitmap.) The present invention, on the 

10 other hand, uses one small top bitmap 425 for each tab, 
as well as a bottom 429, left 423, and right 437 pieces, 
or their shaded versions 425A, 429A, 423A, 437A 
respectively, and right overlap 431A and left overlap 
439A pieces all of which are significantly smaller than 

15 the whole. This difference becomes even more 

significant where the number of tabs is larger. As with 
the button control, the top and bottom tab bitmaps 425, 
429 respectively can be extended and therefore the 
actual bitmaps are extremely small, just a few pixels 

20 wide and therefore consume a very small amount of cache 
memory . 

Another advantage to the present invention is that 
if the form changes so that the tab control has 
additional tabs, no further bitmaps need to be 

25 transferred. All of the necessary bitmaps will have 

been cached. Only the table structure with text labels, 
tab selection information, and references to the bitmap 
files needs to be transferred. 

Yet another advantage is that the present invention 

30 alleviates the need to create more images when a form 
changes. For example, in the prior art, if a tab 
control comprises seven individual tab control elements, 
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seven different images must have been created - each one 
having a different tab selected. If it becomes 
necessary to add an eighth tab control element, eight 
new images must be created. In the present invention, 
5 no further images need to be created. 

Preferably, these bitmaps are arranged by placing 
them in a table structure. For example, the code below 
defines an HTML table in which the positions and files 
containing the bitmaps are specified. 

10 Also, in a preferred embodiment, the selected tab 

(whose associated form is displayed) is colored 
differently and rendered differently than the non- 
selected tabs. Thus there are different images for 
selected and non- selected tab parts. However, since a 

15 label is simply text and no image is used, a label's 
background color is specified within the corresponding 
table entry to match the tab. There is no image file to 
be transferred. 

The following sample code produces a file tab 

20 control with five tabs labeled W VS" , "LAB" , "AE" , "CM" , 
and U CMP" respectively, with W VS" indicated as the 
selected form. 

<HTML> 

<i -///////////////////// ii i ii 1 1 iiiii 1 1 1 1 1 1 1 1 1 1 1 a 1 1 1 1 

25 --> 

<•--// Copyright (c) 1997-1998 Phase Forward Inc. 

- - > 

<!--// 51 Winchester Street, Newton MA 02161 

--> 

30 <!--// All Rights Reserved 

<!"////////////////////////////////////////////////// 
--> 

<HEAD> 
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<META HTTP - EQUI V= " Content - Type " content=" text /html ; 
charset=iso-8859-l"> 

<TITLE>Phase Forward Demo CRF Navigation Bar</TITLE> 

< STYLE > 
5 BODY 
{ 

margin-top: Opx; 
margin-left: Opx; 
margin-right : Opx; 
10 margin-bottom: Opx; 

} 

TD 

{ 

vertical -align: bottom; 

15 } 

TD. tabselect 

{ 

color: #FFFF00; 

font-size: lOpt; 
20 font-family: Arial,"Sans Serif"; 

font -weight : bold; 

text - al ign : center ; 

vert ical - align : center ; 

1 ine - height : 8pt ; 
25 height: llpt; 

} 

TD . tabnotselect 
{ 

color: #CCCCCC; 
30 font -size: lOpt; 

font-family: Arial,"Sans Serif"; 

font -weight : bold; 

text -align: center; 

vertical-align: center; 
35 line-height: 8pt; 

height: llpt; 

} 

A: link 
{ 

40 color: #CCCCCC; 

font-size: lOpt; 

font-family: Arial,"Sans Serif"; 
font -weight : bold; 
text -decoration : none ; 
45 text -align: center; 

} 

A:visited 
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{ 

color: #CCCCCC; 
font -size: 10pt; 

font-family: Arial,"Sans Serif"; 
5 font-weight: bold; 

text -decorat ion : none ; 
text - al ign : center ; 

} 

A: hover 
10 { 

color: #FFFFCC; 

} 

</STYLE> 
</HEAD> 

15 <B0DY BGCOLOR= "#666666 "> 

<MAP NAME="OffMidMapl"> 

<AREA SHAPE="poly" HREF= " tab_vsbp . htm" 
COORDS=" 0,1, 4, 1,10,6,15,20,15,24,0,24" 
TITLE= "Vital Signs/Blood Pressure "> 
20 <AREA SHAPE="poly" HREF=" tab_lab.htm" 

COORDS="27, 1,22,1,17,6,14,10,17,20,17,24,27,24, " 
TITLE= "Laboratory" > 

</MAP> 

25 <MAP NAME="OnMidLMap2"> 

<AREA SHAPE="poly" HREF= " tab_lab . htm" 

COORDS = "0,1,4,1,10,6,15,20,15,24,0,24" 
TITLE= "Laboratory" > 

</MAP> 

30 

<MAP NAME="OnMidRMap3"> 

<AREA SHAPE="poly" HREF=" tab_cm.htm" 

COORDS="27, 1,22, 1,17, 6, 14, 10, 17,20,17,24,27,24, » 
TITLE= " Concomitant Medications " > 

35 </MAP> 

<MAP NAME="OffMidMap4"> 

<AREA SHAPE="poly» HREF=" tab_cm.htm" 

COORDS="0, 1,4,1,10,6,15,20,15,24,0,24" 
40 TTTLE=" Concomitant Medications" > 

<AREA SHAPE="poly" HREF= " tab_cmp . htm" 

COORDS== "27, 1,22,1, 17,6,14, 10, 17,20,17,24,27,24, " 
TITLE=" Study Compliance" > 

</MAP> 
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< TABLE BORDER= 11 0 " CELLPADDING= " 0 " CELLSPACING="0" 
HEIGHT= "100%"> 
<TR> 

<TD VALIGN= "bottom" xTABLE BORDER= " 0 " 
5 CELLPADDING= " 0 " CELLSPACING="0 " ALIGN= "left" > 

<TR> 

<TD R0WSPAN="3" NOWRAPxA 
HREF= " tab_vsbp . htm" ><IMG 
SRC=" ./images/ tab_off_l.gif" BORDER= " 0 " 
10 ALT= "Vital Signs/Blood Pressure" ></A></TD> 

<TD NOWRAPxA HREF=" tab_vsbp.htm" xIMG 

SRC=" ./images/tab_of f__top.gif" B0RDER= " 0 " 
WIDTH="52px" HEIGHT="5" ALT= "Vital 
Signs/Blood Pressure" x/Ax/TD> 
15 <TD R0WSPAN="3" NOWRAPxIMG 

SRC=" ./image s/tab_of f_mid.gif " BORDER="0" 
USEMAP= " #Of f MidMapl » x/TD> 
<TD NOWRAPxA HREF= » tabJLab . htm" xIMG 

SRC=" . /images/tab_of f_top.gif" BORDER= " 0 " 
20 WIDTH="40px" HEIGHT="5" 

ALT= 11 Labor at ory " > < /A> < / TD > 
<TD ROWSPAN="3" NOWRAPxIMG 

SRC=" . /images/ tab_on_mi dl .gif" BORDER= " 0 " 
USEMAP="#OnMidLMap2 11 x/TD> 
25 <TD NOWRAPxIMG SRC=" . /images /tab_on_t op . gif » 

BORDER= " 0 " WIDTH="32px" HEIGHT=" 5" 
ALT= "Adverse Experiences "x/TD> 
<TD ROWSPAN=»3" NOWRAPxIMG 

SRC= " . /images/tab__on_midr . gif " BORDER= 11 0 " 
30 USEMAP= " #OnMidRMap3 " x/TD> 

<TD NOWRAPxA HREF=" tab_cm.htm" xIMG 

SRC=» ./images/tab_of f_top.gif " BORDER= " 0 " 
WIDTH="34px" HEIGHT= "5" ALT= "Concomitant 
Medications "x/Ax/TD> 
35 <TD ROWSPAN="3" NOWRAPxIMG 

SRC=" ,/images/tab_of fjnrdd.gif " BORDER^ " 0 " 
USEMAP= " #Of f MidMap4 " x /TD> 
<TD NOWRAPxA HREF="tab_cmp. htm" xIMG 

SRC=" ./images/ tab_pff_top.gif » BORDER= " 0 " 
40 WIDTH="43px" HEIGHT="5" ALT=" Study 

Compl i ance " x / Ax /TD> 
<TD ROWSPAN="3" NOWRAPxA 
HREF= » tab_cmp . htm" x IMG 
SRC=" ./images/tab_of f_r.gif " BORDER="0 I 
45 ALT="Study Compliance" x/Ax/TD> 

</TR> 
<TR> 
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<TD CLASS="tabnot select" BGCOLOR="#336699" 
NOWRAPxA HREF=" tab_vsbp.htm" TITLE= "Vital 
Signs/Blood Pressure" >VS/BP</Ax/TD> 

<TD CLASS="tabnotselect" BGCOLOR="#336699" 
NOWRAPxA HREF=" tabJLab.htm" 
TITLE=" Laboratory ">LAB< /Ax /TD> 

<TD CLASS="tabselect" BGCOLOR="#003366" 

TITLE= "Adverse Experiences" NOWRAP>AE</TD> 

<TD CLASS="tabnot select" BGCOLOR- "#336699" 
NOWRAPxA HREF=» tab_cm.htm" 

TITLE=" Concomitant Medications" >CM</Ax/TD> 
<TD CLASS="tabnotselect" BGCOLOR="#336699" 
NOWRAPxA HREF=" tab_cmp.htm" TITLE=" Study 
C omp 1 i anc e " > CMP < / Ax / TD > 

</TR> 
<TR> 

<TD BGCOLOR="#336699" NOWRAPxA 
HREF= » tab_vsbp . htm" x IMG 

SRC=" ./ images/ tab_of f_bot.gif" BORDER= " 0 " 
WIDTH="52px" HEIGHT="5" ALT= "Vital 
Signs/Blood Pressure" x/Ax/TD> 
<TD BGCOLOR= "#336699" NOWRAPxA 
HREF= " t ab_l ab . htm" > < IMG 

SRC=" ./images/ tab_of f_bot.gif " BORDER= " 0 " 

WIDTH="40px" HEIGHT="5" 

ALT= " Laboratory " x / Ax /TD> 
<TD BGCOLOR="#003366" NOWRAPxIMG 

SRC= " . /images/tab_onJbot . gif " BORDER= " 0 " 

WIDTH="32px" HEIGHT="5" ALT= "Adverse 

Experiences" x/TD> 
<TD BGCOLOR="#336699" NOWRAPxA 

HREF= " t ab_cm . htm" x IMG 

SRC=" ♦ /images/ tab_off_bot .gif " BORDER= " 0 " 
WIDTH=»34px" HEIGHT= I, 5" ALT=" Concomitant 
Medications " x/Ax/TD> 
<TD BGCOLOR="#336699" NOWRAPxA 
HREF= " tab_cmp . htm" xIMG 

SRC=" ./images/tab_of f_bot.gif " BORDER= " 0 " 
WIDTH="43px" HEIGHT= f, 5" ALT=" Study 
Comp 1 i ance " x / A x / TD > 
<TD VALIGN=" bottom" C0LSPAN="3" NOWRAPxIMG 
SRC=" ./ images/ tab_of f_bot.gif " WIDTH="1000" 
HEIGHT="5" BORDER= " 0 " x /TD> 

</TR> 
</TABLEx/TD> 
</TR> 
< /TABLE > 
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</BODY> 
</HTML> 

The correlation between bitmaps from Fig. IOC and 
their corresponding file names is given in the table 
5 below: 



Pig. IOC ref. number 


Filename in HTML code 






423A / 423 


tab_on_l.gif / tab_off_l.gif 


425A / 425 


tab_on__top.gif / tab_off_top.gif 


429A / 429 


tab_on_bot.gif / tab_off_bot.gif 


431A 


tab_on_midr . gi f 


43 9A 


tab_on_midl . gif 


437A / 437 


tab_on_r.gif / tab_off_r.gif 



Similarly, Figs. 11A, 11B and 11C illustrate a 
linear control, preferably a time-line control, of the 

15 present invention using the same technique. Fig. 11C 
shows the various bitmaps that are placed in a table 
structure to compose a linear control. The dashed lines 
show the outline of the bitmap, while the solid lines 
represent what is actually seen. Of course, color and 

20 shading can be used to produce a more dramatic effect, 
and in fact are used in the preferred embodiment. 

Bitmap 481 defines the left end of the control and 
shows the left end of a frame which encloses the 
control. Similarly bitmaps 482, 483 and 489 define top, 

25 bottom and right frame pieces respectively of the 

control enclosure. Note that by defining a bitmap to 
span multiple rows or columns within a table entry does 
not change the appearance of the bitmap except to extend 
it in the vertical or horizontal direction respectively. 
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Bitmaps 483, and 485-488 define the various parts 
of the linear control itself. Bitmaps 483 and 488 are 
the left and right pieces respectively of the control 
and in the preferred embodiment are only used once per 
5 control. Bitmap 485 is the line part of the control and 
is used simultaneously in several places. Bitmap 486 
has a continuation of the control line, plus a vertical 
tick. Bitmap 487 is used to show which value has been 
selected. 

10 These bitmaps 481-489 can be assembled in various 

combinations to create linear controls of any size, and 
to show any control in any particular state. For 
example, in Fig. 11A, bitmaps 481-489 (from Fig. 11C) 
have been assembled into a table 451 to create a linear 

15 control with four stops. In addition, labels have been 
placed in the table below each stop. These labels are 
merely text entries with a background color matching the 
control, so that there is negligible overhead in 
obtaining the labels. 

20 The following HTML code produces the linear control 

of Fig. 11A. 

<HTML> 

<!"////////////////////////////////////////////////// 
--> 

25 <!--// Copyright (c) 1997-1998 Phase Forward Inc. 

- -> 

<!--// 51 Winchester Street, Newton MA 02161 

- - > 

<!--// All Rights Reserved 

30 --> 

<!"////////////////////////////////////////////////// 
--> 

<HEAD> 

<META HTTP-EQUIV=» Content -Type" content =" text /html ; 
35 charset=iso-8859-l"> 

<TITLE>Phase Forward Demo Visit Bar</TITLE> 
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<STYLE> 
BODY 
{ 

margin-left: Opx; 
5 margin- top: Opx; 

} 

TD 

{ 

font-size: 8pt ; 
10 font-family: Arial,"Sans Serif" 

font -weight : bold; 
t ext - al ign : center ; 
vertical -align: middle; 

} 

15 TD.tdselect 

{ 

color: #FFFF00; 

} 

A: link 
20 { 

color: #CCCCCC; 
font-size: 8pt; 

font-family: Arial, n Sans Serif" 
font -weight : bold; 
25 text -decoration: none; 

text - al ign : center ; 
vertical -align : middle ; 
line-height : llpx; 
height: 8px; 

30 } 

A: visited 
{ 

color: #CCCCCC; 

font -size: 8pt; 
35 font-family: Arial,"Sans Serif" 

font -weight : bold; 

text -decoration : none ; 

text - al ign : center ; 

vertical - al ign : middle ; 
40 line-height: llpx; 

height : 8px; 

} 

A: hover 

{ 

45 color: #FFFFCC; 

} 

TD. tickmark 

{ 
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vert ical -align : middle ; 
/*line-height : 12px; 
height: 12px;*/ 

} 

5 </ STYLE > 
</HEAD> 

<BODY BGCOLOR="#33 6699"> 



< TABLE BORDER="0" CELLPADDING= " 0 " CELLSPACING=" 0 » 
HEIGHT= 11 100% M ALIGN="left n VALIGN= " top" > 
10 <TR> 

<TD ROWS PAN= " 3 " >< I MG 

SRC=" . /images/tick_indent_l .gif " 
BORDER= ,, 0"x/TD> 
<TD COLSPAN="2 ,! xIMG 
15 SRC=" ./images/tick_indent_top.gif M BORDER= " 0 " 

WIDTH="53" HEIGHT- » 5" ></TD> 
<TD COLSPAN="3"xIMG 

SRC=" ./ images/ t ick_indent_top.gif" BORDER= " 0 " 
WIDTH="70» HEIGHT= 11 5 " ></TD> 
20 <TD COLSPAN="3 ,! xIMG 

SRC= ,! ,/images/tick_indent_top.gif " BORDER= " 0 " 
WIDTH^^O" HEIGHT= " 5 " ></TD> 
<TD COLSPAN="3 M xIMG 

SRC=" ./images/t ick_indent_top.gif" BORDER=»0» 
25 WIDTH= n 70" HEIGHT="5"x/TD> 

<TD COLSPAN="3 M xI]yiG 

SRC=" ./images/ tick_indent_top.gif" BORDER= n 0 " 
WIDTH= M 70 ,, HEIGHT= ,! 5"x/TD> 
<TD COLSPAN="3 n xIMG 
30 SRC=" ./images/tick_indent_top.gif " BORDER= " 0 " 

WIDTH="70 n HEIGHT="5 " x/TD> 
<TD COLSPAN="3"xIMG 

SRC=" ./images/ tick_indent_top.gif" BORDER="0 ,! 
WIDTH= n 70" HEIGHT="5 !l x/TD> 
35 <TD COLSPAN="2"xIMG 

SRC=" ./images/tick_indent_top.gif » BORDER= B 0 " 
WIDTH="46 n HEIGHT="5"x/TD> 
<TD ROWSPAN=»3"xIMG 

SRC=" . /images/t ick_indent_r.gif" 
40 BORDER= "0" x/TD> 

</TR> 
<TR> 

<TD CLASS="tickmark"xA HREF= » tl_wk-4 . htm" 
TITLE=»»xIMG SRC=" . /images/tickJLef t .gif " 
45 BORDER=»0"x/Ax/TD> 
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<TD CLASS* "tickmark ,, xIMG 

SRC= » . / images/t ickJL ine . gif " BORDER= " 0 » 

WIDTH*" 35" HEIGHT* "3 "x/TD> 
<TD CLASS* "tickmark" x IMG 
5 SRC*" ./images/tick_line.gif " BORDER* " 0 11 

WIDTH* "26" HEIGHT="3"x/TD> 
<TD CLASS*" tickmark" xA HREF*"tl_wk-2 .htm" 

TITLE* " " xIMG SRC=" ./images/tickjniddle.gif " 

BORDER* " 0 « x/Ax/TD> 
10 <TD CLASS*" tickmark" xIMG 

SRC= n . /images/tick_line.gif " BORDER* " 0 " 

WIDTH* "26" HEIGHT="3"x/TD> 
<TD CLASS*" tickmark" x IMG 

SRC=" ./images/ tick_line.gif" BORDER*" 0" 
15 WIDTH* "26" HEIGHT*"3"x/TD> 

<TD CLASS* "tickmark" xA HREF* "tl_wk0 .htm" 

TITLE* " " xIMG SRC* " . / images /tickjniddle . gif " 

BORDER* " 0 " x/Ax/TD> 
<TD CLASS*" tickmark" xIMG 
20 SRC=" ./images/tickJLine.gif " BORDER* " 0 " 

WIDTH* "26" HEIGHT="3"x/TD> 
<TD CLASS = "tickmark"xIMG 

SRC*" ./images/ tick_line.gif" BORDER*" 0" 

WIDTH="26" HEIGHT="3"x/TD> 
25 <TD CLASS* " tickmark" xA HREF*" tl_wkl . htm" 

TITLE=""xIMG SRC=" . /images /tick_middle .gif " 

BORDER* " 0 » x /Ax/TD> 
<TD CLASS*" tickmark" xIMG 

SRC= n ./images/tick_line.gif " BORDER* " 0 " 
30 WIDTH* "26" HEIGHT*" 3" ></TD> 

<TD CLASS* " tickmark" xIMG 

SRC*" ./images/t ickJLine.gif" BORDER* " 0 " 

WIDTH* "26" HEIGHT="3"x/TD> 
<TD CLASS= ,, tickmark"xIMG 
35 SRC=" ./images/tick_middle_selected.gif " 

BORDER* "0"x/TD> 
<TD CLASS="tickmark"xIMG 

SRC=» ./images/tickJLine.gif " BORDER* " 0 " 

WIDTH="26" HEIGHT="3"x/TD> 
40 <TD CLASS*" tickmark" xIMG 

SRC=" ./images/t ick_line.gif" BORDER* " 0 " 

WIDTH* "26" HEIGHT="3"x/TD> 
<TD CLASS*" tickmark" xA HREF* " t l_wk4 . htm" 

TITLE="»xIMG SRC=" . /images/ tick_middle . gif " 
45 BORDER*" 0"x/Ax/TD> 

<TD CLASS* "tickmark" x IMG 

SRC* » ./images/t ick_line.gif » BORDER*" 0" 

WIDTH="26" HEIGHT="3"x/TD> 
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<TD CLASS= n tickmark n ><IMG 

SRC=" ./images/tick_line.gif " BORDER= " 0 " 
WIDTH= f, 26'» HEIGHT = 11 3 11 ></TD> 
<TD CLASS= ,l tickmark ,, xA HREF= " t l_wk5 . htm" 
5 TITLE=»»xIMG SRC=" ./images/tickjniddle.gif " 

BORDER= « 0 " ></Ax/TD> 
<TD CLASS= n tickmark"xIMG 

SRC=" ./images/tick_line.gif ' 1 BORDER= !1 0" 
WIDTH="26" HEIGHT= " 3 " x /TD> 
10 <TD CLASS= f! tickmark"xIMG 

SRC=" . /images/tick_line.gif " BORDER= " 0 " 
WIDTH= ,f 28 n HEIGHT= !, 3 u x/TD> 
<TD CLASS= !, tickmark»xA HREF = " t l_wk8 . htm " 

TITLE= n "xIIVIG SRC=" ./images / tick_right.gif " 
15 BORDER="0 n x/Ax/TD> 
</TR> 
<TR> 

<TD COLSPAN="2"xIMG 

SRC=" ./images/tick_indent_bot .gif " BORDER= " 0 " 
20 WIDTH= ,, 53 ,! HEIGHT= " 5 " ></TD> 

<TD COLSPAN="3"xIMG 

SRC=" ./images/tick_indent_bot .gif " BORDER= " 0 11 
WIDTH="70" HEIGHT="5"x/TD> 
<TD COLSPAN="3 n xIMG 
25 SRC=" ./images/t ick_indent_bot.gif" BORDER= " 0 " 

WIDTH="70" HEIGHT="5"x/TD> 
<TD COLSPAN="3 n xIMG 

SRC=" ./images/t ick_indent_bot.gif" BORDER= " 0 " 
WIDTH= n 70 n HEIGHT= f, 5 I! x/TD> 
30 <TD COLSPAN="3"xIMG 

SRC=" . /images/tick_indent_bot .gif " BORDER= " 0 " 
WIDTH="70" HEIGHT="5"x/TD> 
<TD COLSPAN= lf 3"xIMG 

SRC= " . /images/tick_indent_bot .gif 11 BORDER= " 0 " 
35 WIDTH="70" HEIGHT=»5" x/TD> 

<TD COLSPAN="3 n xIMG 

SRC=" ./images/t ick_indent_bot.gif" BORDER= 11 0 11 
WIDTH="70" HEIGHT= I! 5 " x/TD> 
<TD COLSPAN=»2 M xIMG 
40 SRC=" . /images/tick__indent_bot .gif 11 BORDER= " 0 " 

WIDTH="46" HEIGHT=»5"x/TD> 

</TR> 
<TR> 

<TD COLSPAN=»3" STYLE= ' text -align : left ' 
45 BGCOLOR="#336699" NOWRAPxA HREF="tl_wk-4 .htm" 

TITLE= 11 Placebo Run-in Visit l">  Week 
–4</Ax/TD> 
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<TD C0LSPAN="3 n BGCOLOR= » #336699 " NOWRAPxA 

HREF= ,? tl_wk-2.htm" TITLE=" Placebo Run- In Visit 
2»>Week –2</Ax/TD> 

<TD C0LSPAN="3" BGCOLOR= "#336699 " NOWRAPxA 
5 HREF="tl_wkO .htm" TITLE= "Baseline Visit » >Week. 

0</Ax/TD> 

<TD C0LSPAN="3" BGCOLOR= " #336699 " NOWRAPxA 

HREF=" tl_wkl.htm" TITLE= "Treatment Visit l">Week 
1</Ax/TD> 

10 <TD COLSPAN="3" CLASS= " tdselect " BGCOLOR= " #336699 " 

TITLE= "Treatment Visit 2" NOWRAP>Week 2</TD> 
<TD COLSPAN="3" BGCOLOR= " #336699 " NOWRAPxA 

HREF="tl_wk4 .htm" TITLE=" Treatment Visit 3">Week 
4</Ax/TD> 

15 <TD COLSPAN="3" BGCOLOR= "#336699" NOWRAPxA 

HREF=" tl_wk5.htm" TITLE= "Treatment Visit 4 
(Optional) ">Week 5</Ax/TD> 
<TD COLSPAN="3" STYLE= 1 text -align: right 1 

BGCOLOR="#336699" NOWRAPxA HREF=" tl_wk8 . htm" 
20 TITLE= "Final Visit" >Week 8</Ax/TD> 

</TR> 
</TABLE> 
</BODY> 
</HTML> 



25 Note in addition that certain table entries have 

anchors, denoted by the <Ax/A> element pair. An HREF 
specification within an <A> element specifies the source 
of a document of image file. Those parts of the control 
corresponding to table entries having anchors with HREF 

30 specifications will cause a message to be sent to the 
server when a user clicks in the entry area, requesting 
the specified document. The server processes that 
request, returning pertinent information about the 
selected week in the form, and at the same time, 

35 resending the table with the references to the image 

files reordered so that the control will appear with the 
user's selection selected and with a form appropriate 
for a particular visit. Thus the control appears to 
work as the user would normally expect, yet all of the 



WO 99/63473 



-50- 



PCT/US99/12406 



work is done at the server. In addition, none (or at 
most one) of the bitmaps need to be downloaded because 
they have already been used and should be cached at the 
browser. Thus the transmission from server to client 
5 will not be hampered by a need to download many bitmaps. 
Without the present invention, it is necessary to 
download from the server a very large bitmap comprising 
the entire control in a particular state, say with the 
first tab selected. For each state having a different 

10 tab selected, a separate, large bitmap of the entire tab 
control must be sent from the server if not already 
cached, and when these large bitmaps are cached, each 
consumes a very large amount of available cache memory. 
Fig. 11D illustrates a variation of the time-line 

15 control 490 in which the time-line is further subdivided 
with small ticks 491 which do not have their own 
associated labels, yet each is associated with a 
different copy of a bitmap and a HREF. For example, the 
ticks 491 may represent weeks within a month. Because 

20 each tick 491 has its own bitmap, the user can click on 
one to move the pointer 492 to a particular week. 

Finally, in a further embodiment of the present 
invention, an individual bitmap may itself be sectioned, 
each section being mapped to a different indicator or 

25 URL, or no URL at all. For example, the file tab HTML 
code above uses HTML tags <USEMAP>, <MAP> and <AREA> to 
specify two different URLs corresponding to the left tab 
and right tab within the tab_off_r bitmap. That part of 
the bitmap not corresponding to any tab is not mapped to 

30 an URL. 

Protocol -version dependent forma 
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For various reasons, it is common during a trial 
for the protocol to undergo changes. Related forms must 
be changed to fit the new protocol when this happens. 
However, data entered before the change, i.e. in the old 
5 protocol, must be presented in a form corresponding to 
the old protocol under which it was entered. 

In addition, as stated earlier, a protocol change 
may need to be reviewed by an Institutional Review Board 
at each site before it can be implemented. This can 
10 result in there being two or more active protocols at 

the same time. Again, the data must be presented in the 
form corresponding to the protocol in which the data was 
entered. 

Fig. 12A is a flowchart illustrating the process at 

15 the server in deciding how to deliver a form to the 

browser depending on the study protocol version control. 
At block 601, a request is received from a client. The 
server determines what the correct study protocol 
version should be for the request based on date and time 

20 by looking up the protocol version of the CRF when data 
was first entered in the CRF. At block 605, the server 
determines whether the necessary form (CRF) already 
exists. If so the form is loaded and populated with the 
correct data (block 607) . Otherwise, the form is 

25 created (block 609) . Finally, in block 611, the correct 
populated form is returned to the requesting client. 

Figs. 12B and 12C illustrate a CRF as it might 
appear in a first protocol (ref . 620 in Fig. 12B) and as 
it might appear in a second protocol (ref. 622 in Fig. 

30 12C) . In Fig. 12B, the CRF 620 has three items 621, 

623, 625. Perhaps at the beginning of the trial, it was 
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established that blood pressure would be measured twice 
and entered into items 623 and 625. 

At some point during the trial, it is decided to 
change the protocol so that blood pressure is to be 
5 measured three times. The CRF would then appear as in 
ref . 622 in Fig. 12C, having an additional item 627 
corresponding to the new third measurement . 

Of course, for visits occurring prior to the 
protocol version change, there would only be two blood 
10 pressure measurements on file, and so the CRF as 
portrayed in Fig. 12B (ref. 620) is retrieved and 
displayed when a user examines those visits. 

Integrated help 

In prior art applications, help is often available 

15 in the form of a help button, or a help link. 

Typically, the user clicks on the help button or link, 
and a general help page, often accompanied with a table 
of contents and/or a topic index, is retrieved from the 
server and displayed, replacing the original page. To 

20 find help, the user must search through the table of 

contents or the index, sometimes through several layers. 
To return to the original page, the user must either go 
back by clicking on a "Back" button in the browser, or 
optionally by clicking on a "Back to Document" -type link 

25 or button that is typically available on the help page. 
Several steps are thus required to obtain help about a 
specific topic and then return to the original page for 
which help was needed. 

An innovative aspect of the present invention is 

30 the use of context sensitive help in a Web document. As 
seen in Fig. 13A, the text of each question comprises a 
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link to one of several trial-related documents. For 
instance, the text 801 "Height" for item 4 is such a 
link. When the user clicks on the text 801, a separate 
help window 803 pops open, as in Fig. 13B, and context 
5 sensitive help 804 is transferred from the server and 
displayed in the help window 803. This context 
sensitive help 804 has information specific to the text 
801 clicked on - here there are specific instructions as 
to how to measure height, e.g. shoes off. Thus the user 

10 does not have to look for the subject in an index or 
table of contents, and the original page is still 
available - the user can close the help window at any 
time and the original page has not been affected. 

Preferably, help comes from one of three standard 

15 sources defining the clinical trial: a protocol 

document, an investigative brochure, or a study guide. 
Note that the help window 803 comprises additional 
button controls 805 which enable the user to go directly 
to related information in any of the three documents. 

20 In addition, a help button 807 is always available 

in the main panel 251A. Clicking on this button 807 
brings up a general help window 809, from which a user 
can browse through a table of contents 810 or an index 
811 for the clinical trial documents. Again, additional 

25 buttons 805 allow the user to choose a specific 

document. Figs. 13E and 13F show sample help screens 
for the protocol document 811 and study guide 812 
respectively. 

EQUIVALENTS 

30 While this invention has been particularly shown 

and described with references to preferred embodiments 



